home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / July 96 / ODF 1+ < prev    next >
Encoding:
Internet Message Format  |  1996-08-01  |  2.2 KB  |  [TEXT/ttxt]
  1. Subject:     ODF 1+
  2. Sent:        7/24/96 11:32 AM
  3. Received:    7/24/96 11:41 AM
  4. From:        Adam Nash, adamnash@CS.Stanford.EDU
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. Hi everyone,
  9.  
  10.         As a new ODF developer, I've been extremely impressed with the
  11. state of the framework, and the abilty to develop parts.  We just finished
  12. the Developer University class on ODF (which comes highly recommended, in
  13. my book).
  14.  
  15.         Several of us, though, collaborated to produce a list of features,
  16. problems, etc with ODF.  I thought that I'd throw them out there, in case
  17. there is well know thought or answers to some of them.
  18.  
  19.         1)  Undo support.  We had many debates as too why this isn't
  20. mandatory for FW_CCommand subclasses.  It seems that every non-trivial part
  21. we made that didn't support undo led to sever instability from maligning
  22. the expected state for other command objects.  It seemed much easier to
  23. make the undo method pure virtual, and then the few objects that do not
  24. require undo could just overload it empty.
  25.  
  26.         2) None of the ODF examples seem to undo the Copy command, ie,
  27. restoring the contents of the clipboard to what they were before the copy.
  28. Every action had ramifications...
  29.  
  30.         3) The whole Idler/Repeater issue.  Currently, any FW_CEventHandler
  31. can have a DoIdle routine, but this seems to defeat the nice, mixin
  32. architecture we have.  Why not go back to having a FW_MIdler mixin class,
  33. ala LPeriodical in PowerPlant?  In addition, I sorely missed methods to
  34. repeat, ie, every event do something as opposed to every NULL event do
  35. something.  Many of us found that in PowerPlant coding we used repeaters
  36. *far* more often than idlers, and then used timing functions to prevent
  37. overkilling event processing.
  38.  
  39.         4) Good time support.  Basically, this just implies a simple
  40. utility class that maps to a MicroSeconds or TickCount equivalent.  It
  41. would need to be cross-platform, since otherwise we would just use the
  42. toolbox.
  43.  
  44.         Otherwise, fantastic job on ODF!  We were all extremely impressed
  45. with the framework, and especially the example code and the attentiveness
  46. to pushing forward.
  47.  
  48.         - Adam
  49.